masterofmagicfandomcom-20200216-history
Talk:Disenchant Area/@comment-69.176.107.2-20131114142028/@comment-1333593-20190722210141
Actually, it depends on which side you're on. The spells that fail if you're the attacker will work correctly when you're defending and vice versa. Furthermore, with the Disenchants, if there are any non-unit spells to remove, then whether they get bugged on the unit spells is random. Literally. EDIT: correction. Disenchant Area and Disenchant True fail the exact same way every time. They target Combat Enchantments first, of which they always consider the attacker's to be the ones to remove. Then they target Magic Vortices, followed by Town Enchantments, and in both cases they will target all of them, regardless of whose they are. Finally, for Unit Curses/Enchantments, what they target depends on either a) their spell index, if there were no dispel attempts made before getting here, or b) the "owner" of the success chance, in 1/250s, used as a battle unit index. The bug is caused by using an "uninitialized" variable as the caster ID, which is taken as a battle unit index, meaning that it's multiplied by the structure size (110 bytes), added to the battle unit base pointer, and whatever is 53 bytes ahead from there will be the unit owner - essentially the player casting the spell. For both Disenchant Area and Disenchant True, the variable used here is the Target index argument of the parent function, which is always 99. Since this is now a rather common mistake I keep finding, I know what is in that particular area of the memory. I call it the "Wrack entity", because it falls into the image data area of the Wrack Combat Enchantment icon. Its "owner" is player 12, which will be used by both Disenchants as the casting player's index. This is used by the functions for 4 things. The first of these is setting an "Opponent_Index" variable, which defaults to the attacking player unless the player index matches the "Acting_Player" global variable, which in this case it never can. The next is determining the Combat Enchantment offset (0 or 1), which sets out which side's CE's the Disenchant will try to remove. Naturally, it will always be the attacking player's. The third and fourth uses are similar, they check whether the Node the battle is taking place in belongs to this player, and if it doesn't, the Disenchant will try to remove Warp Node from it. Finally, when Town Enchantments are looked at, their owner is compared to the "Player_Index" to see if their removal should be attempted. Since these comparisons will always return false, in both cases the Disenchants will attempt to remove everything. This is everything that Disenchants do themselves. For dispelling from units, they actually call the Dispel Magic function for the tile of every live unit on the map. Which is where things get a bit more complicated. The Dispel function has the exact same bug, except it uses a different variable for its battle unit index. Or, to be more precise, they both use a CPU register, and two different ones at that. In the case of the Dispels, this is the spell index of the same parent function that has the target index for the Disenchants. Except, when called through the Disenchant function, this value will be overwritten if there was any non-unit spell to dispel - with the dispel chance of the effect in question. As a result, they will show consistent behaviour when there are no non-unit effects to remove, but will be seemingly random when there are. However, as far as the logic involved goes, the "Player Index" is only used to branch whether it's Curses or Enchantments that will be targeted. In fact, it is very much possible that for both combatants, it is the Enchantments that get removed, because that is the default unless the "Player_Index" happens to match the actual owner of the unit. Although the human player's zero index is somewhat more common than the other 5 values.